The OMA DRM is a DRM system specified by the OMA, a consortium of mobile phone and device manufacturers and mobile service providers. The scheme is implemented on many mobile phones and is intended to be used by mobile content providers to add DRM to their products and services. Two versions of the OMA DRM have been released: OMA DRM 1.0 and OMA DRM 2.0.
OMA DRM 1.0 addressed schemes for basic management of digital rights for content objects. As such, it did not provide strong protection for either the content object or the rights object. OMA DRM 1.0 specifies three methods of delivery: Forward Lock (which prevents the user from forwarding content to other users or devices), Combined Delivery (a combined rights object and media object), and Separate Delivery (separate rights object and media object). The OMA DRM 1.0 was designed to handle small-sized media objects such as ring tones or wallpapers for phones.
OMA DRM 2.0 improves and extends the OMA DRM 1.0 delivery mechanism. A device compliant with OMA DRM 2.0 has an individual certificate based on a DRM public key infrastructure (PKI), i.e., each device has a public key, a corresponding private key, and a certificate verifying this fact. Each rights object (RO) is protected for both confidentiality (by encryption) and integrity (by digital signatures). The use of PKI, encryption, and integrity checking strengthens the security of the OMA DRM 2.0 system compared to that of the OMA DRM 1.0 system.
OMA DRM 2.0 also specifies a set of protocols that together are called the Rights Object Acquisition Protocol (ROAP) that comprises various sub-protocols related to mutual authentication and registration between a device and a rights issuer (RI), requesting ROs, response to delivery of ROs or refusal to deliver ROs, and joining and leaving of domains by the device.
The following are some of the main entities defined in the OMA DRM:
Actor—An actor is an external entity that carries out use cases.
Backup/Remote Storage—Transferring ROs and Content Objects (COs) to another location with the intention of transferring them back to the original device.
Combined Delivery—A OMA DRM 1.0 method for delivering protected content and the RO. The RO and the protected content are delivered together in a single entity, the DRM message.
Confidentiality—The property that information is not made available or disclosed to unauthorized individuals, entities, or processes.
Composite Object—A CO containing one or more media objects by means of inclusion.
Connected Device—A device capable of directly connecting to an RI using an appropriate protocol over an appropriate wide area transport/network layer interface.
Content—One or more media objects.
Content Issuer (CI)—The entity making content available to the DRM agent.
Content Provider—An entity that is either a CI or an RI.
Device—A user equipment with a DRM agent. It can be either a connected device or an unconnected device, but this distinction is contextual and variable in nature, since a connected device can become an unconnected device when it loses its capability to directly connect to an RI.
Device Revocation—The process of an RI indicating that a device is no longer trusted to acquire ROs.
Device RO—An RO dedicated for a particular device by means of the device's public key.
Domain—A set of devices, which are able to share domain ROs. Devices in a domain share a domain key. A domain is defined and managed by an RI.
Domain Identifier—A unique string identifier of the domain key.
Domain Key—A 128 bit symmetric cipher key.
DRM Agent—The entity in the device that manages permissions for media objects on the device.
DRM Content—Media objects that are consumed according to a set of permissions in an RO.
DRM Time—A secure, non-user changeable time source. The DRM time is in the UTC time format.
Integrity—The property that data has not been altered or destroyed in an unauthorized manner.
Join Domain—The process of an RI including a device in a domain.
Leave (De-Join) Domain—The process of an RI excluding a non-revoked device from a domain.
Media Object—A digital work or a composite object.
Network Service Provider—The entity providing network connectivity for a mobile device.
Permission—Actual usages or activities allowed by the RI over DRM content.
Play—To create a transient, perceivable rendition of a resource.
Protected Content—Media objects that are consumed according to a set of permissions in an RO.
Restore—Transferring the protected content and/or ROs from an external location back to the device from which they were backed up.
Revoke—Process of declaring a device or RI certificate as invalid.
Rights Issuer (RI)—An entity that issues ROs to OMA DRM conformant devices.
RI Context—Information that was negotiated with a given RI during the 4-pass Registration Protocol such as RI ID, RI certificate chain, version, algorithms, and other information. An RI Context is necessary for a device to successfully participate in all the protocols of the ROAP suite, except the Registration Protocol.
Rights Object (RO)—A collection of permissions and other attributes which are linked to protected content.
Rights Object Acquisition Protocol (ROAP)—A protocol that enables devices to request and acquire ROs from an RI.
ROAP Trigger—An extensible markup language (XML) document including a URL that, when received by the device, initiates the ROAP.
Stateless Rights—ROs for which the device does not have to maintain state information.
Stateful Rights—ROs for which the device has to explicitly maintain state information, so that the constraints and permissions expressed in the RO can be enforced correctly. An RO containing any of the following constraints or permissions is considered Stateful Rights: <interval>, <count>, <timed-count>, <datetime>, <accumulated> or <export>.
Super-Distribution—A mechanism that (1) allows a user to distribute protected content to other devices through potentially insecure channels and (2) enables the user of that device to obtain an RO for the super-distributed protected content.
Unconnected Device—A device that is capable of connecting to an RI via a connected device using an appropriate protocol over a local connectivity technology, e.g., OBEX over IrDA (object exchange over infrared), Bluetooth, or Universal Serial Bus (USB). An unconnected device may support DRM Time.
User—The human user of a device. The user does not necessarily own the device.
FIG. 1 is an overview of the existing OMA DRM 2.0 functional architecture 100. The architecture 100 consists of a DRM system 102, a content provider 104, and a user 106. The DRM system 102 includes a CI 110, an RI 112, DRM agents 114, a network store 116, and removable media 118. The CI 110 distributes protected content 122 and the RI 112 distributes an RO 124. The DRM agents 114 redistribute the protected content 122.
The CI 110 is an entity that delivers DRM content 122. The OMA DRM defines the format of the DRM content 122 to be delivered to DRM agents 114 and the way that the DRM content 122 can be transported from the CI 110 to the DRM agent 114 using different transport mechanisms. The CI 110 may do the actual packaging of the DRM content 122 itself or it may receive pre-packaged content from some other source.
The RI 112 is an entity that assigns permissions and constraints to the DRM content 122 and generates ROs 124. An RO 124 is an XML document expressing permissions and constraints associated with the DRM content 122. ROs 124 govern how the DRM content 122 may be used; the DRM content 122 cannot be used without an associated RO 124 and may only be used as specified by its associated RO(s). DRM content could be associated with more than one RO if, for example, the RO has a time expiration (e.g., 10 days), and after the time expiration a new RO would be needed to access the content.
The DRM agent 114 is a logical entity that is responsible for managing point-of-consumption enforcement of the DRM content 122. The DRM agent 114 embodies a trusted component of a device, and is responsible for enforcing the permissions and constraints for the DRM content 122 on the device, controlling access to the DRM content on the device (which can only be accessed through the DRM agent 114), and so on.
The DRM content 122 is packaged to protect it from unauthorized access before it is delivered. The CI 110 delivers the DRM content 122, and the RI 112 generates the RO 124. The CI 110 and the RI 112 embody logical roles, rather than physical entities, in the system 102. For example, in one deployment, content owners may pre-package DRM content, which is then distributed by a content distributor acting as both CI and RI.
An RO 124 governs how the DRM content 122 may be used. DRM content 122 cannot be used without an associated RO 124, and may only be used according to the permissions and constraints specified in the RO 124. The OMA DRM makes a logical separation of DRM content from ROs. DRM content and ROs may be requested separately or together, and they may be delivered separately or at the same time. When they are delivered at the same time, they are typically both provided by the CI 110, with the RO and the content embedded in a DRM Content Format (DCF).
An RO 124 is cryptographically bound to a specific DRM agent 114 by a set of keys, so only that specific DRM agent 114 can access it. The DRM content 122 can only be accessed with a valid RO 124, so the content 122 can be freely distributed or super-distributed.
The OMA DRM 2.0 allows one RO to be bound to a group of DRM agents. Such a group is called a domain. DRM content and ROs distributed to a domain may be shared and accessed offline by all DRM agents belonging to that domain. For example, a user may purchase DRM content for use on both her phone and her PDA.
The OMA DRM specifications define the format and the protection mechanism for DRM content (or the DCF), the format (rights expression language (REL)) and the protection mechanism for the RO, and the security model for management of encryption keys. The OMA DRM specifications also define how the DRM content and the ROs may be transported to devices using a range of transport mechanisms, including pull (HTTP pull, OMA download), push (WAP push, MMS), and streaming. However, the OMA DRM specifications do not address any interaction between network entities, e.g., between the CI 110 and the RI 112.
The following is a non-exhaustive list of the use cases covered by the OMA DRM 2.0 specifications.
1. Basic Pull Model
A user selects content to download by browsing to a Web site, and confirms the terms of the purchase. The CI 110 identifies and protects the content 122, i.e., packages it. The content 122 is encrypted using the content encryption key (CEK). The device capabilities can be detected using advertised MIME-type support, etc. The RI 112 generates an RO 124 for the content 122 and the target DRM agent 114. The RO 124 includes the permissions for the content transaction and the CEK. Lastly, the RO 124 is cryptographically protected by encryption (using an RO encryption key, or REK) and digital signatures, and is bound only to the target DRM agent 114. The DRM content 122 and the protected RO 124 are then delivered to the DRM agent 114.
2. Push of DRM Content
An alternative distribution model is to push the content directly to a device using Multimedia Messaging Service (MMS), WAP Push, or a similar method, without a preceding discovery process. There are two variations on this use case.
2A. Content Push
The CI 110 and/or the RI 112 may have certain prior knowledge of a user and a particular DRM agent 114, so that the content 122 and an RO 124 can be formatted and packaged for delivery.
2B. Push-Initiated Pull
In this case, the CI 110 and/or the RI 112 may have no prior knowledge about the user or their DRM agent 114, but may still wish to deliver content, e.g., to allow the user to preview the content 122 to entice them to purchase the content. Instead of pushing the DRM content 122 directly to a user, a link to the content or a link to the preview of the content can be sent. Following the link will take the user to a specific location and then the procedure continues as in the basic pull model.
3. Streaming of DRM Content
Both the basic pull and the push use cases assume that the content is packaged and delivered in its entirety. Alternatively, the content may be packetized and delivered as a stream. In this case, the stream itself is protected (encrypted). The exact format of the encryption has been left out of the scope of OMA DRM, and can be chosen from existing encryption standards. The streams may be protected with encryption schemes which are different from those specified by OMA for download, to address possible packet loss, etc. After the stream is encrypted, though, access to the stream can be controlled through the same procedure as described earlier for discrete content. An RO is generated, the stream encryption key is put in the RO just like a CEK would be, and the RO is then cryptographically bound to a DRM agent.
4. Domains
Domains are an optional feature and may not be supported by all RIs. Domains expand the basic model of the OMA DRM 2.0 where the ROs and the CEK are bound to a specific DRM agent 114, and allow an RI 112 to bind rights and CEKs to a group of DRM agents instead of just a single DRM agent. Users may then share the DRM content 122 off-line between all DRM agents belonging to the same domain. An RI 112 may use the domain concept to provide new services, such as enabling users to access DRM content 122 from several devices that they own or provide support for unconnected devices where users purchase the DRM content and rights via one device (e.g., a PC) for later use on another device (e.g., a portable player).
5. Back-Up
The DRM content 122 can be stored on removable media 118, in a network store 116, or in some other form of storage. The DRM content 122 is stored in encrypted form and can only be accessed by a particular target DRM agent 114 using an associated RO 124. ROs 124 can be stored for backup purposes if the RO only contains stateless permissions. The security model ensures that the RO 124 is protected and can only be accessed by the intended DRM agent 114, even if the RO 124 is stored off-device. Some permissions require maintenance of state by the DRM agent 114, e.g., a limited number of plays. Such ROs cannot be stored off-device, as this might result in loss of the state information.
6. Super-Distribution
The DRM content 122 can be copied and transferred to other DRM agents 114, e.g., a user sending the DRM content 122 to a friend. The friend, in order to access the content 122, is taken to the RI 112 via a link in the DRM content package to acquire an RO 124.
7. Export (to Non-OMA DRM Systems)
The DRM content 122 may be exported to other DRM systems, for use on devices that are not OMA DRM compliant, but support some other DRM mechanism. The OMA DRM architecture allows RIs 112 to, if they wish, express permission for DRM agents 114 to perform conversions to specific other DRM systems, possibly as specified by the other DRM system. The RI 112 may limit the export only to specific external DRM systems.
8. Support of Unconnected Devices
The OMA DRM enables a connected device to act as an intermediary to assist an unconnected device to purchase and download content 122 and ROs 124. A user, for example, may have an OMA DRM compliant portable device (an unconnected device) that has no network connectivity, and an OMA DRM compliant mobile device (a connected device) that has network connectivity. After using the connected device to browse and purchase the DRM content 122 and downloading the DRM content 122 to the connected device, the user then may wish to play the DRM content 122 on the unconnected device. In this case, the DRM agent 114 on the connected device requests and downloads a domain RO 124 from the RI 112.
The DRM agent 114 on the connected device then embeds the domain RO 124 in the DCF. The DCF can then be transferred to the unconnected device using an appropriate protocol over a local connectivity technology, e.g., Bluetooth or USB. Both the connected device and unconnected device must be OMA DRM compliant to support this functionality. Also, the unconnected device must belong to the same domain as the connected device.
Security and Trust
The following is an overview of the OMA DRM 2.0 security and trust measures. In general, any DRM solution needs to meet two security requirements: (1) the protected content must only be accessed by properly authenticated and authorized DRM agents; and (2) permissions on the protected content must be honored by all DRM agents. Enforcement of the permissions and constraints associated with the DRM content are the main concern of the security and trust measures of any DRM scheme. Unauthorized access to DRM content beyond what is stipulated by the associated RO and creation of illegal copies and redistribution of DRM content constitute the main threats to any DRM system.
The OMA DRM system provides the means for the secure distribution and management of protected content in the OMA environment and meets the requirements specified above. The OMA DRM enforces the use and protection of the content and the ROs at the point of consumption by using a DRM agent that ensures protected use of content under the constraints of the ROs.
The basic steps for distributing DRM content can be summarized as follows:
1. Content packaging. Content is packaged in a secure content container (DCF). The DRM content is encrypted with a symmetric content encryption key (CEK). The content can be pre-packaged, i.e., content packaging does not have to happen on the fly. The same CEK is not used for all instances of a piece of content, although this is not a requirement in the OMA DRM.
2. DRM agent authentication. All DRM agents have a unique private/public key pair and a certificate. The certificate includes additional information such as device maker, device type, software version, serial numbers, etc. This allows the Cis and the RIs to securely authenticate a DRM agent.
3. RO generation. The RO contains the CEK, which ensures that the DRM content cannot be used without an associated RO. ROs are made up of permissions (e.g., play, display, and execute) and constraints (e.g., play for a month, display ten times). ROs may also include constraints that require a certain user to be present (e.g., determined by a user identity) when the content is accessed. These permissions and constraints, along with other information embodied in the RO (e.g., copyright information), may be presented to the user.
4. RO protection. Before delivering the RO, sensitive portions of the RO (such as the CEK) are encrypted with a rights encryption key (REK), and the RO is then cryptographically bound to the target DRM agent. This ensures that only the target DRM agent can access the RO, the CEK, and the DRM content. In addition, the RI digitally signs the RO. The RO also governs access to the DRM content by including the CEK. The OMA DRM Rights Expression Language (REL) specifies the syntax (XML) and semantics of permissions and constraints governing the use of the DRM content. An RO has its own MIME content type.
5. Delivery. The RO and the DCF can now be delivered to the target DRM agent. Since both items are inherently secure, they can be delivered using any transport mechanism (e.g., HTTP/WSP, WAP Push, MMS). The RO and the DCF can be delivered together, e.g., in a MIME multipart message or can be delivered separately.
The OMA DRM trust model for the ROs is based on the public key infrastructure (PKI), whereby there are groups of principals, verifiers and one or more authentication authorities recognized and trusted by both. A single entity can play both as a principal and a verifier depending on the needs of the context and solutions chosen. The PKI enables a verifier to authenticate the identity and other attributes of a principal when they communicate over an open, unsecured network. In such a system, typically, the verifier does not have to maintain any sensitive information about the principals it interacts with, for the purposes of authentication. In addition, the Certification Authority (CA) is not directly involved in transactions between principal and the verifier. An RI trusts a DRM agent to behave correctly if the DRM agent's certificate is verifiable by the RI and has not been revoked. Similarly, a DRM agent trusts an RI to behave correctly if the RI's certificate is verifiable by the DRM agent and has not been revoked.
The primary entities of the PKI as applied to the OMA DRM are the CAs, the devices, and the RIs. The authentication and key transfer protocols of the OMA DRM require the RI to be able to authenticate the device and the device to be able to authenticate the RI. Such mutual authentication is accomplished by the ROAP.
In addition, devices are assumed to be provisioned (either at manufacturing time or later) with device public and private keys and associated certificates signed by an appropriate CA. Based on the certificate preferences expressed by the RI, the device has to provide an appropriate certificate. Devices are required to store the private keys in local storage with integrity and confidentiality protection.
The RIs are also provided with public keys, private keys, and certificates signed by a CA. The certificate chain (a chain of multiple certificates including the certificate of the public key owner signed by one CA and zero or more additional certificates of CAs signed by other CAs) is presented to the device at the time of the authentication protocol for validation of the certificate chain of trust.
It is noted that multiple CAs may exist in the DRM system. The ROAP protocol requires that the CA signing the RI certificates runs an Online Certification Status Protocol (OCSP) responder for use during the execution of the protocol. The CAs are also required to define the appropriate certificate policies to govern the use of the issued certificates.
The following describes the main aspects of OMA DRM security.
1. Confidentiality, which ensures that data is not accessible by an unauthorized party. As stated above, the protected content must only be accessible by properly authenticated and authorized DRM agents. To achieve this goal, protected content is encrypted. Encryption keys are unique to each media object, and ROs carry the encryption keys wrapped in keys only accessible by the intended recipients.
2. Authentication, which is the process by which a party identifies itself to another party. In the OMA DRM, mutual DRM agent and RI authentication is achieved in the 4-pass Registration Protocol, the 2-pass RO Acquisition Protocol, and the 2-pass Join Domain protocol. Depending on the protocol used and the message sent, authentication is achieved either through digital signatures on nonces or on time stamps. The 1-pass RO Acquisition Protocol achieves RI authentication through the digital signature on a time stamp. It does not authenticate the DRM agent to the RI, but due to the protected content being wrapped with the recipient's public key, authentication is done indirectly through key binding. The 2-pass Leave Domain Protocol authenticates the DRM agent to the RI through the digital signature on a time stamp. It does not authenticate the RI to the DRM agent. RIs are required to authenticate themselves to the DRM agent during delivery of ROs. This provides some level of assurance about the authenticity of the RI.
3. Data Integrity Protection ensures the ability to detect unauthorized modification of data. In the OMA DRM, data integrity protection, when applicable, is achieved through digital signatures on ROAP messages and ROs.
4. Key Confirmation ensures the recipient of a message containing a protected key that the message sender knows the key value. In the DRM context, this property protects against unauthorized re-issuance of ROs from one RI by another. In the OMA DRM system, key confirmation is achieved through a medium access control (MAC) over the protected key and the sending party's identity by using parts of the protected key as the MAC key.
The DRM agent has to be trusted by the RI, both in terms of correct behavior and in terms of a secure implementation. In the OMA DRM, each DRM agent is provisioned with a unique key pair and an associated certificate, identifying the DRM agent and certifying the binding between the agent and this key pair. This allows RIs to securely authenticate the DRM agent using standard PKI procedures.
The information in the certificate enables the RI to apply a policy based on its business rules, the value of its content, etc. For example, an RI may trust certain manufacturers, or it may keep an updated list of DRM agents that are known to be trusted or not trusted according to some criteria defined by the RI.
The DRM Content Format (DCF) is a secure content package for encrypted content, with its own MIME content type. In addition to the encrypted content, it contains additional information such as content description (original content type, vendor, version, etc.), RI uniform resource identifier (URI) (a location where an RO may be obtained), and so on. This additional information is not encrypted and may be presented to the user before an RO is retrieved. The CEK needed to unlock the DRM content inside a DCF is contained within the RO. Thus, it is not possible to access DRM content without the RO, and the DRM content can only be used as specified in the RO. The OMA DRM includes a mechanism allowing a DRM agent to verify the integrity of a DCF, protecting against modification of the content by an unauthorized entity.
The OMA DRM system assumes the presence of DRM time in the DRM agent. Since users are not able to change the DRM time, a mechanism is defined by which the DRM time can be synchronized with the time held by an OCSP responder. Some constraints (e.g., absolute time constraints), as well as some aspects of the delivery protocol for ROs, rely on the DRM agent having a secure time source. DRM time in the context of the OMA DRM specifications means an accurate time as well as a time value that is not changeable by users. The OMA DRM specifications provide mechanisms for the DRM time to be synchronized when necessary, e.g., if the DRM time is lost after a prolonged power failure. Some limited-capability unconnected devices may not support a real time clock and hence may not support DRM time. Connected devices, however, must support DRM time.
The OMA DRM protects against RO replay protection attacks. An example of an RO replay attack is where an intermediary intercepts an RO with a limited number of plays during delivery to the DRM agent. When the rights expire on the DRM agent, the intercepted RO might be delivered again (replayed) from the intermediary. The OMA DRM prevents this and similar attacks from occurring.
The OMA DRM system provides application-layer security through the use of the security mechanisms listed above. Hence, it does not rely on, or assume, transport layer security.
The ROAP plays a central part in the OMA DRM 2.0 in allowing secure, authentication-based exchange of information regarding ROs. The ROAP is the common name for a suite of DRM security protocols between an RI and a DRM agent in a device. The protocol suite contains several sub-protocols:
1. The 4-pass protocol for registering a device with an RI, as shown in FIG. 2.
2. The 2-pass RO acquisition protocol includes the request and delivery of an RO, as shown in FIG. 3.
3. The 1-pass RO acquisition protocol relates to the delivery of an RO from an RI to a device (e.g., messaging/push), as shown in FIG. 4.
4. The 2-pass join domain protocol for a device to join a domain, as shown in FIG. 5.
5. The 2-pass leave domain protocol for a device to leave a domain, as shown in FIG. 6.
FIG. 2 is a flow diagram the 4-pass registration protocol 200. The protocol 200 utilizes a device 202, an RI 204, and an OCSP responder 206. The device 202 initiates (possibly upon receipt of a ROAP trigger) the contact with the RI 204 by sending a Device Hello message (step 210), which contains information such as the device ID (a hash of a device's certificate that the RI 204 can later check with the OCSP responder 206) and other information. Table 1 illustrates the main components in the Device Hello message. None of the information in the Device Hello message is integrity protected, i.e., there is no signature for the message.
TABLE 1Format of the Device Hello messageMandatoryParameteror OptionalNotesVersionMandatory<major.minor> representation of the highest ROAP versionnumber supported by ROAP. This value is 1.0 for OMA DRMv2.0. The device has to support all versions including andprior to the version specified.Device IDMandatoryCurrently, the only ID defined is the SHA-1 hash of thedevice's public key information, as it appears in thecertificate (i.e., the complete Distinguished Encoding Rules(DER)-encoded SubjectPublicKeyInfo component in thedevice certificate). If the device holds multiple keys, it mayselect one or more of these public keys and send thecorresponding device IDs.SupportedOptionalIdentifies the cryptographic algorithms (hash, MAC,Algorithmssignature, key transport, key wrap) identified by commonURIs. All devices and RIs should support the algorithmsspecified in the OMA DRM 2.0.ExtensionsOptionalCertificate Caching, to indicate to the RI that the device hasthe capability to store information in the RI context whetherthe RI has stored the device certificate information or not.The actual storage indicator is done by the Peer KeyIdentifier extension for the device's public key indication.
The RI 204, in response to the Device Hello message (step 210), sends an RI Hello message to the device 202 (step 212), which contains information such as the RI's certificate credentials (in the form of an RI ID), some session related (anti-reply-purpose) nonces and session numbers, and other optional information such as the information on the trust chain about the device that the RI 204 recognizes. Table 2 illustrates the format of the RI Hello message. It is noted that none of the information in the RI Hello message is integrity protected.
TABLE 2Format of the RI Hello messageROAP-RI HelloStatus =Status notParameter“Success”“Success”NotesStatusMandatoryMandatoryIndicates whether the Device Hellomessage handling was successful ornot.Session IDMandatory—Protocol session ID set by the RI.SelectedMandatory—Minimum of (device suggestedVersionROAP version, highest RIsupported ROAP version).RI IDMandatory—The only currently defined ID is thehash of the RI's public keyinformation, as appearing in theRI's certificate. If the RI holdsmultiple keys, the RI must selectonly one key.SelectedOptional—Cryptographic algorithms to use inAlgorithmsubsequent ROAP interactions.RI NonceMandatory—A random nonce sent by the RI.TrustedOptional—List of device trust anchorsdevicerecognized by the RI. It is not sentAuthor-if the RI already has a deviceitiescertificate or otherwise can trustthe device.ServerOptional—<=512 byte server-specificInfoinformation that the device latermust return unchanged in theRegistration Request message. Thedevice must not try to interpret thisinformation.ExtensionsOptional—Peer Key Identifier, CertificateCaching, Device Details: byincluding this, the RI requests thedevice to return device-specificinformation (manufacturer, model,etc.) in a subsequent RegistrationRequest message.
Upon successful verification of the information contained in the RI Hello message, the device 202 sends a Registration Request message (step 214) that includes mandatory information such as the request time, session ID, and a signature and optional information such as a certificate chain, trusted RI authority anchor, extensions, etc. Table 3 illustrates the format of the Registration Request message. The Registration Request message contains, at its tail end, a digital signature of all the messages exchanged between the device 202 and the RI 204 up to the Signature field in the Registration Request message, i.e., the entire Device Hello message, the entire RI Hello message, and the fields of the Registration Request message up to (and excluding) the Signature field. This digital signature is made using the device's private key. Including the digital signature provides some integrity protection of the associated ROAP messages.
TABLE 3Format of the Registration Request messageRegistrationParameterRequestNotesSession IDMandatorySame as the session ID in the RI Hello message. If notthe same, then the RI terminates the registrationprotocol.Device NonceMandatoryA nonce chosen by the device.Request TimeMandatoryThe current DRM time as measured by the device.CertificateOptionalA certificate chain includes the device's certificate butChainnot the root certificate. The certificate chain is presentunless the RI Hello message contained the Peer KeyIdentifier extension and its value identified the key inthe device's current certificate. If the RI indicated trustanchor preferences in the RI Hello message, the devicemust select a device certificate and chain which chainsback to one of the trust anchors indicated by the RI.Trusted RIOptionalList of RI trust anchors recognized by the device. IfAuthoritiesempty, it indicates that the RI is free to choose anycertificate.Server InfoOptionalOnly (must be) present if a Server Info parameter waspresent in the RI Hello message. If present, this fieldmust be the same as in the RI Hello message.ExtensionsOptionalPeer Key Identifier; No OCSP Response; OCSPResponder Key Identifier; Device Details(manufacturer, model, version).SignatureMandatoryAn SHA-1 hash of data sent so far in the protocol,excluding this Signature element. Made using thedevice's private key.
Unless the device 202 indicates, via information in the Extensions, that OCSP verification is not necessary or supported, the RI 204 sends an OCSP Request message to the OCSP Responder 206 (step 216) to request verification of the information supplied to the RI 204 by the device 202. The OCSP Responder 206 looks up the information in the request message to attempt to verify the information and returns an OCSP Response message (step 218) containing the results of the request.
The RI 204 sends a Registration Response message to the device 202 (step 220), which include an indication of whether the registration was successful or unsuccessful and other information. Table 4 illustrates the format of the Registration Response message. The Registration Response message contains, at its tail end, an SHA-1 hash of the Registration Request message and the Registration Response message (up to and excluding the Signature field). This digital signature is made using the RI's private key. Including the digital signature provides some integrity protection of the associated ROAP messages. It is noted that while the SHA-1 hash is used for the digital signature, any suitable algorithm for applying the digital signature could be used.
TABLE 4Format of the Registration Response messageRegistration ResponseStatus =Status notParameter“Success”“Success”NotesStatusMandatoryMandatoryIndicates whether the Device Hello messagehandling was successful or not.Session IDMandatory—The protocol session ID set by the RI.SelectedMandatory—The minimum of (device suggested ROAPVersionversion, highest RI supported ROAP version).RI IDMandatory—The only currently defined ID is the hash of theRI's public key information, as appearing in theRI's certificate. If the RI holds multiple keys, theRI must select only one key.SelectedMandatory—Cryptographic algorithms to use in subsequentAlgorithmROAP interactions.RI NonceMandatory—A random nonce sent by the RI.TrustedOptional—List of device trust anchors recognized by thedeviceRI. It is not sent if the RI already has a deviceAuthoritiescertificate or otherwise can trust the device.Server InfoOptional—<=512 byte server-specific information that thedevice later must return unchanged in theRegistration Request message. The device mustnot try to interpret this information.ExtensionsOptional—Peer Key Identifier, Certificate Caching, DeviceDetails: by including this, the RI requests thedevice to return device-specific information(manufacturer, model) in the subsequentRegistration Request message.SignatureMandatory—SHA-1 has of the Registration Request messageand the Registration Response message(excluding the Signature field), using the RI'sprivate key.
FIG. 3 is a flow diagram of the 2-pass RO Acquisition Protocol 300. The protocol 300 utilizes the device 202 and the RI 204, and operates after the 4-pass Registration Protocol 200 has been completed and the device 202 has received a valid certificate chain about the RI 204. The protocol 300 is used by the device 202 to request an RO from the RI 204. The device 202 sends an RO Request message to the RI 204 to request the RO (step 310). Table 5 shows the format of the RO Request message. The RO Request message contains a digital signature of the message (excluding the signature field).
TABLE 5Format of the RO Request messageROAP-RORequestMandatory/ParameterOptionalNotesDevice IDMIdentifies the requesting device.Domain IDOWhen present, identifies the domain.RI IDMAuthorizing RI ID. Same value as in the RegistrationResponse message.Device NonceMA nonce chosen by device.Request TimeMThe current DRM Time, as seen by the device.RO InfoMIDs of the requested RO(s), and also an optional hash ofthe DCF if the device possesses the DCF.CertificateOSent unless the RI context indicates that the device hasChainthe necessary certificate information. Must include thedevice's certificate.ExtensionsOPeer Key Identifier; No OCSP Response; OCSPResponder Key Identifier; Transaction IDSignatureMAn SHA-1 hash of the RO Request message without theSignature element.
The RI 204, in response to the request message, sends an RO Response message to the device 202 (step 312). The RO response message includes an RO or includes an indication that an RO will not be sent.
Table 6 shows the format of the RO response message. The RO Response message, in successful state case, contains a digital signature that is an SHA-1 hash of the RO Request message and the RO Response message excluding the Signature field.
TABLE 6Format of the RO Response message2-Pass2-PassnotParameterSuccessSuccessNotesStatusMMIndicates if the request was handledsuccessfully or not.Device IDM—Identifies the requesting device, in thesame way as in the Device Hello message.This value must be the same as in RORequest message. Must terminate if not.RI IDM—Identifies the RI and must equal the RIID in the RO Request message.DeviceM—Must have the same value as in the RONonceRequest message.ProtectedM—ROs in which sensitive information (suchROsas CEKs) are encrypted.CertificateO—Same as in the Registration ResponseChainmessage.OCSPO—Complete set of OCSP responses for theResponseRI's certificate chain.ExtensionsO—Transaction Identifier that allows the RIto provide the device with information fortracking transactions.SignatureM—An SHA-1 hash of the RO Requestmessage and the RO Response message(without this Signature field) using theRI's private key.
FIG. 4 is a flow diagram of the 1-pass RO Acquisition Protocol 400. The protocol 400 utilizes the device 202 and the RI 204. In the protocol 400, the RI 204 unilaterally sends, without request by the device 202, an RO response message to the device 202 (step 410) including the RO. The protocol 400 applies to the push use cases, for example. Table 7 shows the format of the RO Response message.
TABLE 7Format of the RO Response messageParameter1-PassNotesStatusMIndicates if the request was handled successfully or not.Device IDMIdentifies the requesting device, in the same way as inthe Device Hello message. This value must be the sameas in the RO Request message. Must terminate if not.RI IDMIdentifies the RI and must equal the stored RI ID.Device Nonce—Must have same value as in the RO Request message.Protected ROsMROs in which sensitive information (such as CEKs) areencrypted.CertificateOSame as in the Registration Response message.ChainOCSP ResponseMComplete set of OCSP responses for the RI's certificatechain.ExtensionsOTransaction Identifier that allows RI to provide thedevice with information for tracking transactions.SignatureMAn SHA-1 hash of the RO Response message withoutthis Signature field. The RI's private key is used togenerate this Signature.
FIG. 5 is a flow diagram of the 2-pass Join Domain Protocol 500. The protocol 500 utilizes the device 202 and the RI 204. When the device 202 wants to join a domain, the device 202 sends a Join Domain Request message to the RI 204 (step 510). The RI 204 evaluates the request and sends a Join Domain Response message to the device 202 (step 512). Table 8 shows the format of the Join Domain Request message and Table 9 shows the format of the Join Domain Response message.
TABLE 8Format of the Join Domain Request MessageMandatoryParameteror OptionalNotesDevice IDMIdentifies the requesting device. This valuemust be the same as the stored value from theRegistration Response message.RI IDMIdentifies the RI and must equal the stored RIID from the Registration Response message.DeviceMNonce chosen by the device.NonceRequestMCurrent DRM Time, as seen by the device.TimeUnconnected Devices that do not support DRMTime MUST use the value “Undefined” here.DomainMIdentifies the Domain the device wishes to join.IdentifierCertificateOThis parameter is sent unless CertificateChainCaching is indicated in the RI Context withthis RI. When present, the parameter valueshall be as described for the Certificate Chainparameter in the Registration Responsemessage.ExtensionsOIncludes extensions Peer Key Identifier, NoOCSP Response, OCSP Responder KeyIdentifier, and Hash Chain Support.SignatureMAn SHA-1 hash of the Join Domain Requestmessage (without this Signature field) usingthe device's private key.
TABLE 9Format of the Join Domain Response MessageStatus isStatus =NOTParameterSuccessSuccessNotesStatusMMIndicates if the request was handledsuccessfully or not.Device IDM—Identifies the requesting device. Thevalue returned here must be the same asin Join Domain Request message thattriggered this response.RI IDM—The value returned here must equal theRI ID sent by the device in the precedingJoin Domain Request message.DeviceM—Must have the same value as in theNoncepreceding Join Domain Request message.DomainM—This parameter carries Domain keysInfo(encrypted using Device's public key) aswell as information about the maximumlifetime of the Domain. Devices may use ashorter lifetime than suggested by the RI.CertificateO—This parameter MUST be present unlessChaina preceding ROAP Join Domain Requestmessage contained the Peer Key Identifierextension, the extension was not ignoredby the RI, and its value identified the RI'scurrent key. When present, the value of aCertificate Chain parameter shall be asdescribed for the Certificate Chainparameter of the Registration Responsemessage.OCSPO—A complete set of valid OCSP responsesResponsefor the RI's certificate chain.ExtensionsO—Currently only one extension is definedfor the Join Domain Response message. Itis Hash Chain Support. When thisextension is present it indicates that theRI is using the technique of generationDomain Keys through hash chainsdescribed in the Domain Section. The RIMUST NOT include this extension in theJoin Domain Response unless the sameextension was received in the precedingJoin Domain Request.SignatureM—An SHA-1 hash of the Join DomainResponse message excluding thesignature field itself.
FIG. 6 is a flow diagram of the 2-pass Leave Domain Protocol 600. The protocol 600 utilizes the device 202 and the RI 204. When the device 202 wants to leave a domain, the device 202 sends a Leave Domain Request message to the RI 204 (step 610). The RI 204 evaluates the request and sends a Leave Domain Response message to the device 202 (step 612). Table 10 shows the format of the Leave Domain Request message and Table 11 shows the format of the Leave Domain Response message.
TABLE 10Format of the Leave Domain Request MessageMandatoryParameteror OptionalNotesDevice IDMIdentifies the requesting device. This valuemust be the stored value from the RegistrationResponse message.RI IDMIdentifies the RI and must equal stored RI IDfrom the Registration Response message.DeviceMNonce chosen by the device.NonceRequestMCurrent DRM Time, as seen by the device.TimeUnconnected Devices that do not support DRMTime MUST use the value “Undefined” here.DomainMIdentifies the Domain the device wishes toIdentifierleave.CertificateOThis parameter is sent unless CertificateChainCaching is indicated in the RI Context withthis RI. When present, the parameter valueshall be as described for the Certificate Chainparameter in the Registration Responsemessage.ExtensionsOThe Not a Domain Member extension iscurrently defined for Leave Domain Requestmessage. Presence of this extension indicatesto the RI that the device does not consideritself a member of this Domain (even though itis sending a request for the RI to remove itfrom the Domain). This could happen, forexample, if the device already has left theDomain, but receives a new trigger to leave it(perhaps because the RI never received theprevious ROAP Leave Domain Requestmessage). This extension MUST be included inthe request if the device is not a member of theidentified Domain.SignatureMAn SHA-1 hash of the Leave Domain Requestmessage (without this Signature field) usingthe device's private key.
TABLE 11Format of the Leave Domain Response MessageStatus isStatus =NOTParameterSuccessSuccessNotesStatusMMIndicates if the request was handledsuccessfully or not.DeviceM—Must have the same value as in theNoncepreceding Leave Domain Requestmessage.DomainM—The domain from which the RI removedIdentifierthe device.ExtensionsO—No extensions are currently defined forLeave Domain Response message.
All of the protocols included in the ROAP suite except the 1-pass RO Acquisition Protocol may be initiated using a ROAP trigger. The device 202 may also initiate the protocols unilaterally as a result of user interactions. The RI 204 generates and sends the ROAP trigger to the device 202 to trigger a ROAP protocol exchange. Alternatively, the RI 204 may delegate ROAP trigger generation to other systems by providing the necessary information (such as RO identifiers and domain identifiers) to these systems. A ROAP trigger (whether generated directly or indirectly by the RI 204) may also be transmitted to the device 202 by other systems (e.g., by a CI).
When the device 202 receives the ROAP trigger, it initiates the ROAP protocol exchange as soon as possible. Appropriate user consent must have been obtained prior to initiating any ROAP protocols as a result of receiving a ROAP trigger. Since the ROAP comprises several protocols, the ROAP trigger includes an indication of the actual protocol (e.g., Registration, RO Acquisition, Join Domain, or Leave Domain) to be started by the device 202.
The ROAP messages and how the messages are handled by the protocols provide not only the ROs and their associated processing, but also security functions surrounding the ROs in the OMA DRM 2.0. More specifically, the following security and trust aspects are addressed by the ROAP protocols:
1. Mutual authentication between the RI and the device;
2. Countering replay attacks by using nonces in various messages;
3. Protecting the integrity of the ROAP messages or parts of the ROAP messages; and
4. Verification of secure DRM Time in the ROAP messages or parts of the ROAP messages.
Trusted Computing Techniques
Recently, trusted computing techniques have appeared in the literature and in products, mostly under the technical umbrella of the Trusted Computing Group (TCG). The TCG technologies provide methods whereby computing entities can establish trustworthiness for themselves and for other devices by way of using of a trust chain, so that processing or computing on such devices can be:
1. Assessed for the trustworthiness of the platform and various hardware (HW) and software (SW) components;
2. Validated only when the appropriate trust level is established and can be validated for itself and for others upon external requests; and
3. External parties can perform assessments and decisions on the exchange of information and processing with other devices and is based on the manifested trust levels of such target devices.
The TCG defines a core processing module called the Trusted Processing Module (TPM) that has the following features:
1. Physical protection of the module and its interfaces;
2. Protected volatile and non-volatile storage spaces;
3. Protected cryptographic functions inside the module that can perform encryption and digital signing;
4. Use of Platform Configuration Registers (PCR) that consecutively capture the “state” of the platform and its SW components by hash extending;
5. Existence of device specific and secure Endorsement Keys (EK), based on a PKI that serves as the root of the authentication of the device but not in direct ways. The EK is never exposed outside, but its aliases, called the Attestation Identity Keys (AIKs), are used to sign the platform's integrity measurement values; and
6. Use of “sealing” of data, in conjunction with PCR values signed by AIKs, in memory “blobs”, so that data can be accessed or extracted only when platform or SW integrity (as measured and verified by the matching PCR values from the TPM and from the sealed memory blob) is verified.
Trusted computing techniques were inspected, especially in the context of mobile phone devices, for possible application in securing the DRM application on such mobile devices. Methods previously proposed to secure the DRM application by use of TCG techniques included certain methods that use the procedure of TPM sealing and the memory blobs to securely store the DRM-related data after ROAP protocol processing using TCG keys, in the TPM and in storage areas with key protection.
However, the existing prior art does not explicitly address nor address in an orderly way how to establish and use “trust” on the platform and/or the DRM software. Nor does the prior art address specific techniques to secure the integrity in the ROAP messages, to strengthen the integrity processing in OMA DRM 2.0 systems. The present invention includes new techniques for such purposes.
The current OMA DRM 2.0 specification provides strong security methods based on PKI involving the CA, the RIs, and the device. However, there are vulnerabilities related to the security and integrity of the platforms, SW, agents, and messages both within the OMA DRM 2.0 specification itself and as related to the non-specified implementation of the devices and RIs that are OMA DRM 2.0 compliant.
The OMA DRM specification has acknowledged the various threats and vulnerabilities that any device or RI could face, even when they are conforming to the OMA DRM 2.0 specification. These vulnerabilities include:
1. Entity Compromise, where an attacker may attempt to compromise an entity of the DRM system, physically or otherwise. Types of entity compromise attacks include compromising the DRM agent on the device and the DRM SW in the RI. The consequences of entity compromises include disclosure of private keys, domain keys, RO encryption keys, content encryption keys, and protected content, as well as the loss of integrity protection of the DRM agent's replay cache, for example, and/or the loss of protection of the rights stored internally in the DRM agent. Further, losses of DRM time could also occur. The effects on a PKI of a compromised CA or OCSP Responder is discussed in references such as IETF RFC3280.
The OMA DRM system relies on certificate revocation to minimize the damage caused by a compromised entity. DRM agents and RIs must always verify that the entity they are communicating with has not been compromised, by checking the entity's certificate status. An entity compromise attack can take place in both “forward” and “reversed” ways. A forward compromise attack is on the DRM entities (the RI, the DRM agent, the CI, the CA, or the OCSP responder), leading to unauthorized behavior. A reversed compromise attack neutralizes or weakens a DRM agent's security, integrity settings, and configurations.
2. Message Removal, whereby an attacker may remove a message sent between a DRM agent and an RI, typically resulting in Denial of Service (DoS) attacks. A message removal attack can include: message removal during the registration protocol or the RO acquisition protocol, replay nonce removal, removal of ROAP trigger, etc.
3. Message Modification, whereby an attacker may modify any message sent between a DRM agent and an RI, typically resulting in DoS attacks. A message modification attack can include modification during the registration protocol, during the join domain and leave domain protocols, and to various ROAP triggers.
4. Message Insertion, whereby an attacker may insert messages into the communication channel at any point between an RI and a DRM agent. The attacker may also record messages and try to replay them at a later point in time. A message insertion attack can include messages inserted while in the registration protocol, the 2-pass and 1-pass RO acquisition protocols, and to various ROAP triggers.
5. Other attacks such as general DoS attacks, passive attacks such as traffic analysis, and privacy disclosing.
The following problems of the current OMA DRM specifications and implementations are identified. An expanded notion of “integrity” as applied to the OMA DRM schemes is defined. In the traditional sense, the OMA DRM specifications only address a small scope of ROAP message integrity. In the expanded notion of integrity defined in the present invention, it is noted where and what kind of integrity can be considered in the following.
1. DRM Platform Integrity. This relates to integrity at or within the platform entities, i.e., at the physical entities comprising the device, the RI, and the content functions. The different entities include the operating system (OS), the boot code (e.g., the BIOS in the PC case), the HW/firmware (FW)/SW for memory access, the various HW/FW/SW entities that process security related functions (such as cryptography and key management, as well as privileged storage of secret data such as policies, certificates, etc.), and the network and local connectivity HW/FW/SW. Platform integrity determines whether the platform is valid, genuine, not modified except by legitimate processes, and operates only as intended.
2. DRM SW Integrity. DRM SW refers to software entities and components residing in the device, the RI, or the CI that perform functions specific to OMA DRM specifications and their procedures. At the device, the DRM agent consists of the DRM SW. At the RI and the CI, the DRM SW refers collectively to the set of SW that performs the DRM-specific functions such as RO packaging, DCF formatting, content encryption, content or RO delivery, verification, ROAP processing, etc. DRM SW integrity is maintained if the DRM SW is valid, genuine, not modified except by legitimate processes, and operates only as intended.
3. Integrity of the ROAP messages and information. The integrity of the ROAP messages and their constituent information is maintained if such information is validated, genuine, and not modified except by legitimate processes. In the OMA DRM 2.0 specifications, certain subsets of ROAP messages and their constituent information are integrity protected by use of digital signatures.
4. Integrity of the media object and DRM content. The media objects and the DRM content must also be integrity protected, i.e., must not be modified, removed, or falsely inserted, whether they are stored at the device, the RI, or the CI, or are in transit or delivery between any two parties. Of particular interest is the over-the-air (OTA) delivery of content, as applicable to the transfer of content to a mobile device, where the DRM content is delivered using essentially open channels.
5. Integrity of DRM-related information. DRM-related information such as the entity IDs (device ID, RI ID, etc.), encryption keys (CEK, REK) and signature keys, the ROs themselves, context information, certificates, and other trust-chain related information must be securely protected, which means that they should be protected not only for confidentiality but also for integrity.
It is noted that neither the current OMA DRM 2.0 specifications nor existing prior art appear to have proposed solutions to the entity compromise or integrity problems. This lack of solutions poses the following problem: Even if all the ROAP procedures are correctly implemented as according to the OMA DRM 2.0 specification, for example, how can a device really know whether the RI's platform is trustworthy? In other words, how can the device know whether the RI's platform will not abuse the data that the device sends as part of the ROAP protocols or abuse the DRM processing itself? For example, the device does not know whether the RI will arbitrarily and incorrectly limit the usage rights of the device because the RI's platform SW is compromised and it limits the otherwise valid usage rights of the device. Similar questions arise for the problem of the integrity of the DRM software. More specifically, some of the problems of the current OMA DRM 2.0 systems as viewed from the expanded notion of integrity as described above, are as follows.
1. A lack of methods to check and report the integrity of the platform and the DRM SW. As related to the entity compromise threat identified above, there is no method in the prior art for explicit and structured platform integrity verification and SW agent integrity verification between the device and the RI, either as specified by the OMA DRM 2.0 specifications or as part of the TCG 1.2 Use Cases. This is particularly true for platform integrity verification, rather than just the DRM agent.
2. A platform (such as a PC or PDA, as related to the device, or a server, as for the RI) could be maliciously compromised, which may result in preventing the DRM agent and the RI agent SW from performing correctly, even given correct and confidentiality-protected and integrity-protected information. For example, an otherwise well-protected DRM agent SW may store some information in plaintext in a shared memory prior to, during, or after processing. A compromised platform may, in such cases, egregiously access the shared memory and remove the information, alter the information, or insert new false information, which then could be processed subsequently by the DRM agent SW which may perceive such false information as genuine. This may result in DoS attacks, unauthorized disclosure of private information, or unauthorized delivery, distribution, or consumption of DRM ROs or DRM content.
3. The DRM agent SW and the RI SW, which are pieces of SW that process DRM-related information, may become compromised for various reasons. Such SW, for example, could be altered by a virus or other malicious SW entities. One result of such a compromise in the platform or the DRM SW would be a subsequent compromise in the integrity of the messages and information that the OMA DRM 2.0 considers, especially the ROAP protocol messages. Partly because only some, but not all, of the ROAP messages are integrity-protected, they can in theory be manipulated in synchronized ways between a compromised device and a rogue or compromised RI. Messages could be modified synchronously at both the device and the RI, and still may appear to be “integrity verified”, since the messages were modified in the same way.
4. Insufficient integrity protection of the ROAP messages. As related to the message integrity, the ROAP messages and the information carried by the various message fields are subject to vulnerabilities that are not solved by the OMA DRM 2.0 specification. For example, the ROAP message integrity protection currently specified in the OMA DRM 2.0 specification leaves holes such as:
4A. Not all ROAP messages are integrity protected. Not including digital signatures in all the messages could pose vulnerabilities in certain cases.
4B. Even when ROAP messages or certain fields of information are integrity protected by digital signatures, once such information has been decrypted, integrity checked, and then “used” in plaintext, malicious entities could access the plaintext information and remove, alter, or redistribute the previously integrity-checked information. Thus, a strengthened integrity protection is required.
5. Vulnerabilities regarding the integrity of the DRM content and its delivery. More specifically, the following problems exist:
5A. Content integrity checking mechanisms are incomplete. For example, integrity of the content while the content is in transit or in delivery (e.g., OTA download) is not specified. The signature for the DCF, for example, is only generated for use in the ROAP procedures. Until and before the ROAP procedures take place, there is no integrity checking mechanism that manages the content integrity while in storage at the CI, for example.
5B. Content encryption, even for use in the ROAP protocol, is mandatory but integrity checking is only optional.
5C. Especially for packetized content for streaming services, the PDCF format has a timing issue. Packets that had been illegitimately modified could be downloaded and may even be consumed (i.e., played on a media player) before the integrity of the whole stream can be checked.
The central problem becomes: how can the various parties (the device, the RI, and the CI) be assured of the platform integrity and the DRM SW integrity? Thus, a method to strengthen and verify the integrity of the platform (e.g., the OS, the BIOS, drivers, media player, communication software, shared memory, etc.) upon which either the DRM agent SW or the RI SW rely, is needed. The present invention addresses the shortcomings of the prior art.